FIG. 1 is a simplified block diagram depicting part of a telephone system comprising a public switched telephone network (PSTN) 10, a network applications platform (NAP) 12, and a number of telephony applications, including a voicemail application 14A, a fax application 14B, a call routing application 14C, and a bank-by-phone application 14D.
The basic elements of any telephony application include call flows, functions, and prompts. Call flows define the personality of the application, i.e., the logical flow of the application interface to the caller (the person that dialed a phone number and was transferred to the telephony application in question). Functions represent the software building blocks employed to implement the desired call flow functionality. A function is computer code and may involve access to an application database. Each function produces a result that determines the path of the associated call flow. Prompts are logical groups or sequences of pre-recorded, typically digitized, voice. Prompts are presented to the caller through control of the call flows.
A class of telephony application creation environments employs a modularized approach whereby the basic elements (call flows, functions, prompts) are logically separated both at the time of creation and during execution. In particular, the call flows are maintained in an interpretative state table, functions reside in executable object code, and prompts reside in a database such as, for example, Unisys' SPeech Interface to NAP, or SPIN, database. Further information about Unisys' Network Applications Platform (NAP) can be obtained from U.S. Pat. No. 5,133,004, Jul. 21, 1992, titled "Digital Computer Platform For Supporting Telephone Network Applications."
In a telephone system of the type depicted in FIG. 1, the network applications platform (NAP) 12 could be located at a local telephone company connected to one or more central offices or switches, or could alternatively be located on the premises of a customer of the telephone company, such as a large or medium-sized company. In the latter case, the NAP 12 would typically be connected to a private branch exchange (PBX) instead of a PSTN.
The present invention was devised during the process of developing a service creation environment (somewhat similar to a compiler and editor) for servicing telephone systems employing telephony applications (voicemail, fax, call routing, bank-by-phone, etc.), and particularly for modifying such applications after they are installed in the customer's telephone system. Telephone customers typically demand 100% system availability, which means that, for a large customer having hundreds or even thousands of employees at a given location, it is extremely difficult to take the telephony application off-line (out of service) for even a short time to make updates or modifications. Therefore, when it becomes necessary to modify the call flows, voice prompts, or functions of an application, the application provider needs a way to make such modifications while the application is kept on-line. Moreover, there is a need to coordinate such modifications so that, in a given dialog, the appropriate versions of call flows, voice prompts and functions are invoked. In other words, once a caller enters into a dialog with the application, the application should not change versions of call flows, voice prompts or functions during that dialog. An "active dialog", then, is a concurrent logical communication path between the application and the NAP, that is maintained in an "active" status, provided the necessary operating conditions are present, e.g., the active dialog is not terminated. However, different versions could be in use at the same time for different dialogs. These needs are particularly acute for high volume telephone systems, which typically cannot be taken out of service without inconveniencing at least some users.
In summary, a disadvantage of modularizing telephony applications into call flows, functions, and prompts is that to maintain proper functionality they all need to be updated in a coordinated fashion when changes are made to any one of the parts. Typically, any combination of changes to the parts will require that the application be taken out of service. The goal of the present invention is to provide a mechanism permitting one to make changes to call flows, functions and voice prompts without taking the application out of service. Preferably, all changes should take effect at the same time so that any new caller will be presented with a coordinated set of call flows, functions and prompts. The present invention meets these goals.